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(57) Abstract: The invention relates to a transmission 
of data in a mobile radio network, in particular a trans- 
mission of text and/or image data, with or without sound 
in multimedia messages (MM). During said transmis- 
sion, at least one identification signal for a data record 
or several records is allocated to the data and said identi- 
fication signal(s) is/are transmitted to the receiver of the 
data. 

(57) Zusammenfassung: Bei einer Dateniibertragung 
in einem Mobilfunknetz, insbesondere einer 
Ubertragung von Text- und/oder Bilddaten mit und 
ohne Ton innerhalb Multimedia messages (MM), wird 
den Daten zumindest ein Identifikationssignal fiir 
einen Datensatz oder mehrere Datensatze zugeordnet 
und dieses oder diese Identifikationssignal(e) an den 
Empfanger der Daten ubertragen. 
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Beschreibung 

VERFAHREN UND MOB I LTELEKOMMUNI KATIONSGERAT ZUR DATENUB ERTRAGUNG IN EINEM 
MOB I LFUNKNET Z 

5 Die Erfindung betrifft ein Verfahren zur Datenubertragung in 
einem Mobilf unknetz nach dem Oberbegriff des Anspruchs 1 so- 
wie ein mobiles Telekommunikationsgerat nach dem Oberbegriff 
des Anspruchs 2 6, ein Computerprogrammerzeugnis nach Anspruch 
30, sowie ein Funkkommunikat ions system nach Anspruch 32. ' 

10 

Bisherige Mobilf unknetze, wie etwa das nach dem GSM-Standard 
arbeitende Netz, eroffnen noch recht eingeschrankte Moglich- 
keiten zur Obertragung von Textdaten. So konnen etwa bis zu 
160 Zeichen umfassende Kurznachrichten iibertragen werden. 
15 Diese Einrichtung wird als SMS (Short Message Service) be- 
zeichnet. Fur die Kosten des Versands derartiger Textnach- 
richten hat der Datenversender aufzukommen. 

Zukunftig soil auch eine Ubertragung von Multimediadaten, 
20 insbesondere stehenden oder bewegten Bildern mit oder ohne 
Ton, moglich sein. Es ist mit einer erheblichen Ausweitung 
der Datenubertragungsmengen und der Datentypen innerhalb sol- 
dier Obertragungen zu rechnen, was mit erhohter Obertragungs- 
zeit und einer Kostensteigerung einhergeht. 

25 

Der Erfindung liegt das Problem zugrunde, die Kontrolle der 
Datenubertragung fur Teilnehmer eines Mobilf unknetzes zu ver- 
einf achen. 

30 Die Erfindung lost dieses Problem durch ein Verfahren mit den 
Merkmalen des Anspruchs 1, sowie durch ein Mobiltelekommuni- 
kationsgerat mit den Merkmalen des Anspruchs 2 6, ein Compu- 
terprogrammerzeugnis mit den Merkmalen des Anspruchs 30, so- 
wie durch ein Funkkommunikationssystem nach Anspruch 32. Hin- 
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sichtlich vorteilhafter Ausgestaltungen wird auf die Anspru- 
che 2 bis 25, 27 bis 29 und 31 verwiesen. 

Mit dem erf iridungsgemaBen Verfahren ist eine Information an 
den Datenempf anger tlber Charakteristika der zum Empfang be- 
5 reitstehenden Daten moglich, was diesem die Kontrolle hier- 
iiber erleichtert. 



Bei Vorabzusendung des oder der Charakteristika der zu uber- 
sendenden Daten angebenden Identif ikationssignal (e) ist die 

10 Kontrolle bereits vor Empfang der eigentlichen Daten ermog- 
licht, wobei besonders vorteilhaft dem Empfanger anhand der 
so erhaltenen Information eine Auswahlmoglichkeit eroffnet 
ist, ob er die bereitstehenden Daten jetzt oder spater oder 
gar nicht empfangen mochte. Wenn auch die Wahlmoglichkeit ei- 

15 nes teilweisen Empfangs einer Multimedia message (MM) vorge- 
sehen ist, kann der Empfanger beispielsweise nur fur ihn 
wichtige Kurzinf ormationen, die eine kurze tJbertragungszeit 
benotigen, herunterladen und eventuell zugehorige speicherin- 
tensive Bildbestandteile oder ahnliches spater oder gar nicht 

20 herunterladen. 



Wenn das dafiir eingesetzte Identif izierungssignal Information 
Uber die Grofie eines zu empfangenden Datensatzes enthalt, 
kann der Empfanger daran ermitteln, wieviel Zeit er fur die 
25 Ubertragung und/oder das Studium der Daten rechnen muiJ und ob 
er diese Zeit jetzt oder zu einem spateren Zeitpunkt oder gar 
nicht aufbringen will. 

Wenn das Identif izierungssignal Information uber den Namen 
30 eines Datensatzes enthalt, kann der Empfanger daran ermit- 
teln, aus welchem Themenkomplex die Daten stammen. Auch daran 
kann er vorteilhaft auswahlen, ob er diesen oder diese Daten- 
satz oder Datensatze jetzt oder zu einem spateren Zeitpunkt 
oder gar nicht empfangen will. 



35 
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Besonders vorteilhaft kann im Identif ikationssignal auch In- 
formation tiber den Datentyp gegeben sein, so daJJ der Empfan- 
ger weifi, ob es sich beispielsweise um Bilddaten, Textdaten 
und/oder Musikdaten handelt. 

5 

Kontrolle und Transparenz sind damit entscheidend verbessert. 



Weitere Vorteile und Merkmale der Erfindung ergeben sich aus 
in den Zeichnungen neu dargestellten und nachfolgend be- 
10 schriebenen Ausf tihrungsbeispielen des Gegenstandes der Erfin- 
dung. 



Es zeigen: 



15 Fig. 1 eine schematische Abbildung von einer Dateniibertra- 
gung zugeordneten Sendungen gemafi dem WAP-Standard 
(Wireless application protocoll) zwischen der Ebene 
des Versenders und der des Providers einerseits und 
der Ebene des Providers und der des Empfangers an- 

20 dererseits, 

Fig. 2 die Header-Felder einer nach dem in Fig. 1 gezeig- 
ten WAP-Standard gesendeten Nachricht M-Send.req, 
wobei die erf indungs gemafi neu eingefugten Header- 
25 Felder grau unterlegt sind, 

Fig. 3 eine Spezif izierung des Typs der in Fig. 2 gezeig- 
ten und in den grau unterlegten Feldern abgelegten 
Inf ormationen spwie des zusatzlich im Statusbericht 
30 auftretenden Feldes tiber den Erhalt der versandten 

Daten, 

Fig. 4 eine Darstellung der Zuweisung der Header-Felder 
aus Fig. 2 zu den binclren Codes, wobei die erfin- 
dungsgemafl neu eingefugten Header-Felder grau un- 
35 terlegt sind, 
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Fig. 5 eine ahnliche Darstellung wie Fig, 2 der nach dem 
in Fig. 1 gezeigten WAP-Standard gesendeten Nach- 
richt M-Notif ication. ind (MNI), 

5 

Fig. 6 eine ahnliche Darstellung wie Fig. 2 der nach dem 
in Fig. 1 gezeigten WAP-Standard gesendeten Nach- 
richt M-Retrieve . conf (MRC) , 

10 Fig. 7 eine ahnliche Darstellung wie Fig. 2 der nach dem 
in Fig. 1 gezeigten WAP-Standard gesendeten Nach- 
richt M-Acknowl edge . ind (MAI), 

Fig. 8 eine ahnliche Darstellung wie Fig. 2 der nach dem 
15 in Fig. 1 gezeigten WAP-Standard gesendeten Nach- 

richt M-Delivery . ind. (MDI ) , 

Figuren 
9-17 und 

20 23-25 jeweils exemplarisch den. Inhalt verschiedener In- 

formationssignale fur die Ubertragung von Multime- 
dianachrichten zwischen mehreren Komponenten eines 
Funkkommunikationssysteitis nach dem erf indungsgema- 
Uen Verfahren, 



25 



30 



Figur 18 das Encoding eines einzigen Header-Feld-Namens, 

Figur 19 Encoding (Kodierung) der neuen Parameternamen und 

Parameterwerte im einzigen Headerfeld nach Figur 9, 

Figur 2 0 Zuweisung binarer Codes zu den Feldnamen der Para- 
meter im einzigen Headerfeld nach Figur 9, 



Figur 21A, 21B das einzige Header-Felder einer Multimedia 
35 Service (MMS ) Sendeanfrage (in WAP Message M- 
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Send, req; ) , und 

Figur 22 das zur Sendeanfrage MSreq nach Figur 12A, 12B zuge- 
horige Header-Felder der MMS Empf angerbenachrichti- 
gung (M-Nind; in WAP Message M-Notification.ind ;) 

Elemente mit gleicher Funktion und Wirkungsweise sind in den 
Figuren 1 mit 13 jeweils mit denselben Bezugszeichen verse- 
hen. 

Im Ausfiihrungsbeispiel ist die Anwendung der Erfindung auf 
ein Datenubertragungsschema 1 filr den WAP-Standard, wie es in 
der Ubertragung von insbesondere Bilddaten und f ormatierten 
Textdaten im UMTS-Standard (Universal mobile telecommunicati- 
on standard) Verwendung finden wird, beschrieben. Es versteht 
sich, dafl die Erfindung auch auf andere Standards iibertragbar 
ist . 

Im UMTS-Standard ist vorgesehen, zusatzlich zum bisherigen 
SMS einen sogenannten MMS (Multimedia Messaging Service) fur 
die Ubertragung von Nachrichten, auch als Multimedia messages 
(MMs) bezeichnet, vorzusehen. Damit konnen auch formatierte 
Texte und Bilder mit und ohne Ton iibertragen werden. Die im 
SMS vorhandene Beschrankung auf eine Nachrichtenlange von 160 
Zeichen entfallt. Eine Ubertragung von Audio- und Videonach- 
richten ist moglich. 

MMS ist Uber die Nutzung von WAP realisierbar . Dabei wird fur 
die Funkubertragung von Daten, etwa von Multimedia Messages 
(MMs), das in Fig. 1 dargestellte Protokollschema (WAP WSP: 
Wireless Session Protocoll) angewandt . Dieses umfafit eine E- 
bene 2 eines Datenversenders (auch als MMS User Agent A be- 
zeichnet) , eine Ebene 3 eines Providers (, dessen Netzele- 
ment, das den Service ausfilhrt, auch als MMS Relay bezeichnet 
wird) und eine Ebene 4 eines Empf angers (auch als MMS User 
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Agent B bezeichnet) . Die Ebene 2 des Datenversenders umfaftt 
zumindest ein Telekommunikationsgerat 5, ebenso umfaflt die 
Ebene 4 des Empf angers ein Telekommunikationsgerat 6. Diese 
Telekommunikationsgerate 5, 6 konnen beispielsweise als tlbli- 
5 che Handies oder als Gerate mit weiteren Eingabe- oder Anzei- 
gefunktionen, wie etwa Laptops, ausgebildet sein. 

Eine im Telekommunikationsgerat 5 des Versenders verfaflte o- 
der uber dieses weiterzuleitende Multimedia message abgekurzt 
10 (MM) kann einen oder mehrere Einheiten (Datensatze 7), bei- 
spielsweise einzelne Bilder, Filmsequenzen, Texte oder ahnli- 
ches, enthalten. Die MM wird zunachst als Anf rage-Sendung 9 
(diese tragt im WAP-Protokoll den Namen M-Send.req) an den 
Provider (Ebene 3) versandt. 

15 

Von dort wird die eingegangene Sendung 9 mit der Rucksendung 
10 (M-send. conf ) an den Versender (Ebene 2) quittiert. 

Zeitlich darauf f olgend wird vom Provider (Ebene 3) die Infor- 
20 mation 11 (M-Notif ication . ind) an den Empf anger (Ebene 4) ge- 
sandt, mit der dieser dariiber informiert wird, dafl fur ihn 
eine Nachricht beim Provider 3 zum Herunterladen bereitliegt. 

Hieruber erhalt der Provider 3 beispielsweise automatisch die 
25 quittierende Ruckmeldung 12 (M-Notif yResp . req) vom Telekommu- 
nikationsgerat 6 des Empf angers (Ebene 4) . 

Erst auf Anforderung durch den Empf anger mit der Sendung 13 
(WSP GET. req) wird vom Provider die MM mit der Sendung 14 (M- 
30 retrieve.com) an den Empf anger weitergeleitet . 

Die Nachricht 15 (M- Acknowledge . ind) quittiert den Empfang 
der MM. 

Die abschliefiende Nachricht 16 (M-Delivery . ind) gibt eine 
35 Empfangsbestatigung an den Versender 2 zuruck. 
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Zur Verwaltung der Sendungen 9, 10, 11, 12, 14, 15, 16 dienen 
die sog. Header-Felder , also der eigentlichen MM vorange- 
stellte Felder, in denen Inf orniationen iiber die Herkunft, 
Sendezeit, DateigroBe und weitere Details enthalten sein k6n- 
5 nen. 

Erf indungsgemafS ist die Anzahl der Header-fields erhoht, urn 
zumindest ein weiteres Feld 17, 18, 19, 20, 21, 22, 23 als 
Inf ormationsf eld (er ) iiber charakterisierende Parameter der MM 
10 informieren zu konnen und darin ein oder mehrere Identifizie- 
rungssignal (e) fur diese (n) Parameter dem Empfanger 4 zusen- 
den zu konnen. 

Im Ausfiihrungsbeispiel sind dafiir (sh. Fig. 4) die mit 0x80 
15 bis 0x86 im Hexadezimalsystem adressierten Felder 17, 18, 19, 
20, 21, 22, 23 vorgesehen, urn die Information iiber die Para- 
meter, die weiter unten noch naher beschrieben werden, aufzu- 
nehmen. Auch eine andere Anzahl und/oder Adressierung der zu- 
satzlichen Header-Fields ist moglich. 

20 

Die zusatzlichen genannten Header-Fields 17, 18, 19, 20, 21, 
22, 23 sind zumindest in der Nachricht 11 (M- 
Notif ication. ind) , mit der der Empfanger 4 iiber das Bereit- 
stehen einer MM informiert wird, beigefiigt. Auch die Nach- 
25 richt 9 (M-Send.req) kann, wenn die zusatzlichen Parameter 
vom Versender 2 generiert werden, die zusatzlichen Header- 
Fields 17, 18, 19, 20, 21, 22, 23 enthalten (Fig. 2), ebenso 
die eigentliche MM-Zustellung 14 (M-Retrieve . conf ) (sh. Fig. 
5) oder weitere der Nachrichten 10, 12, 13, 15, 16. 

30 

Unter einem Datensatz 7 einer MM wird im folgenden ein ein- 
zelner Bestandteil einer MM verstanden, der durch seinen Typ 
(z.B. Standbild) und sein Format (z.B. JPEG) definiert ist, 
wobei im MMS auch eine Formatkonvertierung durch das MMS Re- 
35 lay 3 vorgesehen ist, durch die gewahrleistet wird, daii auch 



WO 02/058359 



PCT7EP01/14617 



Telekommunikationsgerate 6 eines Empf angers 4, die nur be- 
stimmte Formate eines Typs unterstutzen, auch nur mit diesen 
Formaten bedient werden. Beispielsweise kann ein Telekommuni- 
kationsgerat 6 nur Standbilder im JPEG-Format anzeigen, was 
5 es im Rahmen seiner Anmeldung dem MMS Relay 3 mitgeteilt hat. 
Das MMS Relay 3 konvertiert dann alle fur diesen Empfanger 
eingehenden Standbilder in das JPEG- Format, wodurch sich im 
allgemeinen die Dateigrofie andert. Dieser Aspekt ist fur eine 
spatere Betrachtung der nach dieser Erfindung neuen Header- 
10 Felder relevant. 

Als Identif ikationssignal konnen beispielsweise die folgenden 
Informationen liber einen Datensatz 7 enthalten sein. Auch ei- 
ne andere Anzahl von Informationen, etwa nur eine Auswahl aus 
15 den auf gef uhrten, kann vorgesehen sein. Die Informationen 
werden dem Empfanger einer MM optional bei Verwendung des 
WAP-Standards (Fig. 1) in der Benachrichtigung 11 {M- 
Notif ication. ind) , und damit vor Obertragung der eigentlichen 
Daten in der Multimedia message, zur Verfugung gestellt. 

20 

Mogliche Parameter von zu libertragenden Daten, insbesondere 
einer MM, uber die der Empfanger vorab informiert wird, sind: 

1. die Anzahl der enthaltenen Datensatze 7 der MM (auch 
25 implizit durch die Beschreibung der einzelnen Elemente 

der MM) , 

2. die jeweilige Grofle (in Octets) eines Datensatzes 1, 

3. der jeweilige Typ und das Format eines Datensatzes 7, 

4. die jeweilige Content ID (Content IDentif ication) eines 
30 Datensatzes eventuell auch relativ zu der Content 

ID/Message ID der gesamten MM, 

5. der jeweilige Name eines Datensatzes, 

6. das Sub jet der gesamten MM, 

7. die Verbindung eines Elements zu einem oder mehreren 
35 anderen Datensatzen 7 der MM, 
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8. die Verbindung der gesamten MM oder eines/mehrerer Da- 
tensatze 7 zu einer oder mehreren URLs/URIs aufiferhalb 
der MM und bei einem solchen externen Link optional die 
Grofie der zu ladenden Daten des/der aufgelosten externen 
5 Links . 

Mit Hilfe der neuen Header-Felder 17, 18, 19, 20, 21, 22, 23 
kann die Methode der " detailed Notification" im MMS umgesetzt 
und der Komfort des MMS fur den Benutzer deutlich erhoht wer- 

10 den. Schon vor dem Laden einer MM und damit voraussichtlich 
schon bevor Kosten ftir den Benutzer entstehen, wird dieser 
uber die Inhalte und die Zusammensetzung der MM detailliert 
informiert und kann entsprechend handeln, etwa dadurch, dafi 
er nur einzelne Datensatze 7 der MM herunterladt und weitere 

15 ablehnt. 

Eine MM besteht grundsatzlich aus einem Header und abhangig 
vom Typ der MM zusatzlich aus einem Datenteil (WAP: Body) . 
Der Header umfalit allgemeine Inf ormationen der MM und setzt 

20 sich aus definierten Header-Feldern zusaitimen. Der Datenteil 

der Message enthalt ein oder mehrere Elemente beliebigen Typs 
(z. B. Texte, Bilder, Tone...), die in beliebiger Reihenfolge 
dem Header folgen. Falls eine Prasentationsbeschreibung im 
Datenteil enthalten ist, soil in einer WAP-Message zu Beginn 

25 des Datenteils ein sogenannter Start-Parameter auf diese Pra- 
sentationsbeschreibung hinweisen . 

Jedes Header-Feld besteht aus einem Feld-Namen, gefolgt von 
einem Feld-Wert, der aus mindestens einem Octet besteht. Die 
Zuweisung von hexadezimalen Werten zu den Feld-Namen ist in 
30 Fig. 4 aufgefiihrt. 

Urn die Benachrichtigung 11 an den Empf anger 4 mit den ge- 
wUnschten Inf ormationen anzureichern, bestehen grundsatzlich 
zwei Moglichkeiten: Entweder werden die Inf ormationen vom 
35 Provider 3 oder vom Versender 2 erstellt. Auch eine Mischform 
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ist moglich. Im einzelnen sind hierfiir die folgenden Ablaufe 
moglich: 

Die Informationen werden aus der am MMS Relay 3 mit der Nach- 
5 richt 9 eintref f enden MM extrahiert, d.h. teilweise aus Hea- 
der-Feldern unverandert tibernommen und teilweise aus dem Da- 
tenteil der . MM berechnet (z.B. die Angabe der Gr5fie eines Da- 
tensatzes 7) . 

Vorteilhaft bei diesera Vorgehen ist die zu erwartende Konsis- 

10 tenz zwischen den beschreibenden Header-Inf ormationen der 
Nachricht 11 und den tatsachlichen Inhalten 14 (in WAP: M- 
Retrieve . conf ) , die auf Anforderung des Empf angers 4 (User 
Agent B) an diesen iibertragen werden, Der Realisierungsauf- 
wand beim Versender 2, und damit i.d.R. im mobilen Endgerat, 

15 bleibt gering. Ein weiterer Vorteil besteht hinsichtlich der 
Genauigkeit der Grofienangabe, wenn Formatkonvertierung statt- 
findet. Bei MMS ist vorgesehen, daJi vor Auslieferung der Da- 
ten eine Anpassung des Inhalts an z.B. Fahigkeiten des emp- 
fangenden MMS User Agents 4 (wie unterstutzte Codecs, Dis- 

20 play-Grofle des Endgerats etc.) oder Vorlieben des Empf angers 
(wie automatische Beschrankung auf eine maximale GrdJJe) durch 
den Service Provider 3 stattfinden kann. Das MMS Relay 3 kann 
dem Empfanger 4 die Grofie des Inhalts nach Datenanpassung 
mitteilen. Dies ist eine Information, die der Versender 2 

25 nicht besitzt. Nachteilig ist der beim MMS-Relay 3 zusatzli- 
che Aufwand zur Generierung der Informationen fur diese 
"detailed Notification", der durch das notwendige "Parsen" 
der MM und die Extraktion der entsprechenden Informationen 
entsteht . 

30 

Die Informationen konnen statt dessen bereits vom Versender 2 
generiert und als Header-Felder 17 ; 18 ; 19; 20 ; 21 ; 22 ; 23 in die 
Nachricht 9 zum Versenden einer MM (in WAP: M-Send.req) ex- 
plizit integriert werden. Vorteilhaft ist die unveranderte 
35 Verarbeitung der MM im MMS Relay 3, das nicht den Inhalt der 
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MM analysieren muiJ . Die Realisierung der mit den neuen Hea- 
der-Feldern 17; 18; 19;20;21;22;23 eroffneten Moglichkeiten im 
Terminal 5 kann vom Hersteller bestimmt werden. Es besteht 
darUber hinaus die Moglichkeit, Endgerate mit unterschiedli- 
5 chen Komf ortmerkmalen anzubieten, Weiterhin kann der MM- 

sendende Teilnehmer 2 sein Wissen iiber die interne und exter- 
ne Verkniipfung der MM-Elemente dem MM-Empfanger in Form von 
detaillierten Inf ormationen mitteilen, welche vom MMS-Relay 3 
lediglich weitergeleitet werden, Eine Generierung der Header- 
10 Felder im MMS Relay 3, die Wissen iiber die interne und exter- 
ne Verknupfung der Datensatze 7 erfordert, ware dort nur 
durch aufwendiges Parsen der MM moglich. Nachteilig ist die 
Erweiterung von Header-Feldern mit teilweise redundanten In- 
f ormationen. 

15 

Vorteilhaft werden die Inf ormationen daher teilweise im sen- 
denden User Agent 2 und teilweise im MMS Relay 3 generiert, 
was auf Seiten des MMS Relay 3 auch die Aktualisierung be- 
reits vorhandener, vom Versender 2 generierter Header-Felder 
20 erf ordert . 

Fur diese Mischform der Generierung zusatzlicher Inf ormatio- 
nen kann folgende Aufteilung der im folgenden erklarten In- 
f ormationen vorgesehen sein: 

25 

Generierung im sendenden User Agent 2: 

• X-Mms-Content-ID: In der bisherigen WAP-Spezif ikation 
fehlen die Moglichkeiten, den Datensatzen 7 eigene zu- 

30 satzliche Header-Felder zuzuordnen (z.B. mit jeweiligem 

Namen und Typ) und mehrere Datensatze 7 hierarchisch an- 
zuordnen. Far eine transparente Konvertierung einer MM in 
eine Internet-Mail (Format gemafl RFC 822 mit Erweiterun- 
gen gemaB MIME (Multipurpose Internet Mail Extensions) ) 

35 werden daher die hier folgenden Vorausset zungen vorge- 
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schlagen: Die zu jeder Extension einer E-Mail moglicher- 
weise zusatzlich im Datenteil der E-Mail codierten Infor- 
mationen (Name, Typ, . . . ) sind transparent auch in einer 
MM enthalt en. Eine Content-ID im Header der MM, die jedem 
Datensatz 7 eindeutig zugeordnet ist, kann als Verweis 
genutzt werden. Der Start-Parameter im Message-Body (= 
Datenstrukturabschnitt, der eigentliche Mitteilungsinf or- 
mation(en) enthalt) muJ5 als Feld definiert sein, das die 
Content-ID (= Inhaltsidentif ikator ) CI des Prasentations- 
beschreibungsobjektes enthalt und damit den Zugriff auf 
dieses Objekt ermoglicht. Mit diesen Vereinbarungen ist 
eine transparente Ubertragung einer MM von einem MMS- 
Relay zu einem beliebigen Empfanger sowohl direkt uber 
ein anderes MMS-Relay als auch tiber das Internet per E- 
Mail moglich. Eine eindeutige Zuordnung zu dem Datensatz 
oder den Datensatzen 7 in der MM ist unbedingt fur die 
erste tibertragung vom sendenden User Agent 2 zum MMS Re- 
lay 3 erf orderlich. 

X-Mms-Content-Type: bezeichnet den Typ und das Format 
des Datensatzes 7. Diese sollten bereits beim Versenden 
eingetragen werden, da der Datensatz 7 nicht unbedingt 
einen Dateinamen wie in einer E-Mail erhalt und dann 
nicht tiber die Dateierweiterung (Extension) einem Format 
zugeordnet werden kann. Eine Aktualisierung dieses Feldes 
durch das MMS Relay 3 ist nur bei einer Format- und/oder 
Typkonvertierung erf orderlich. Der X-Mms-Content-Type 
wird durch den Wert oder das Signal CTV angezeigt und be- 
stimmt . 

X-Mms-content-Size: GroJSe des Datensatzes 7. Dieser wird 
durch Wert bzw. Inhalt CSV angezeigt und bestimmt. 

X-Mms -Cont ent -Name : Name des Datensatzes 7. Dieser Name 
ist nur dem sendenden User Agent 2 bekannt und muli daher 
von ihm eingesetzt werden. Ihm ist der Inhalt CNV zuge- 
ordnet . 
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• x-Mms-External-Link-Flag: Zeigt an, dafi der Datensatz 7 
eine Verkniipfung auf Inhalte aufierhalb der MM enthalt. 
Wenn diese Information vom sendenden User Agent 2 einge- 
setzt wird, ist eine Inhaltsanalyse des Datensatzes 7 

5 durch das MMS Relay 3 entbehrlich. Ihia ist inhaltlich der 

Wert Oder die Zeichenfolge ELF zugeordnet. 

• X-Mms-External-Link-Size : Damit wird die Grofle eines 
verknupften Inhalts auBerhalb der MM angegeben. Dies wird 
durch den Inhalt ELS angezeigt. Da der Datenumfang eines 

10 externen Inhalts nicht an der Verkniipfung selbst abzule- 

sen ist, ist diese Information fur einen Nutzer von gro- 
fiem Interesse. Sie kann direkt bei der Generierung der MM 
im sendenden MMS User Agent 2 erzeugt werden. Alternativ 
ist eine Generierung durch das MMS-Relay 3 moglich, er- 

15 fordert jedoch neben der Analyse der gesamten MM auch den 

Zugriff auf in Referenz angefiihrte Objekt zwecks Grofien- 
bestimmung. 

• X-Mms-Content-Related-URI : Die Information CRV dieses 
Feldes zeigt den Ort eines anderen Elements, auf das der 

20 Datensatz 7 Bezug nimmt, an. Beispielsweise enthalt ein 

Datensatz 7 eine Prasentationsbeschreibung, die sich auf 
andere Elemente mit Audio-, Video- oder anderen Inhalten 
der MM bezieht. Die Generierung dieser Inf ormationen er- 
fordert einerseits Wissen uber die internen Bezuge der E- 

25 lemente einer MM, das auf Seiten des sendenden MMS User 

Agents 2 vorhanden ist, und andererseits Wissen beziiglich 
der Positionen der MM-Elemente beim MMS-Relay/Server 3 
bzw. beim Empf anger 4. Die Inf ormationen konnen auf Sei- 
ten des sendenden MMS User Agents 2 in Header-Feldern co- 

30 diert werden und sind durch das MMS-Relay 3 auf Basis der 

dann aktuellen Positionen zu korrigieren/aktualisieren 
und anschlieJiend im empfangenden MMS User Agent 4 auszu- 
werten . 



35 Generierung bzw. Aktualisierung im MMS Relay 3: 
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• x-Mms-Content-ID: Wird bei Veranderungen Content-ID 
durch das MMS« Relay angepafit. 

• X-Mms-Content-Type: Falls das MMS Relay 3 den Typ 

5 und/oder das Format eines Datensatzes 7 andert, erfolgt 

die entsprechende Aktualisierung des Content-Type* 

• X-Mms-Content-Size: Groiie des Datensatzes 7, angegeben 
in Octets. Nur falls das MMS Relay 3 Typ und/oder Format 
des Datensatzes andert, erfolgt eine Aktualisierung der 

10 die Content-Size betreffenden Information. 



Mit den dif f erenzierten Inf ormationen, die ein Benutzer 4 mit 
der Nachricht 11 (WAP: M-Notif ication . ind) erhalten hat, ist 
ub.er den beispielsweise sof twareseitig in einem Menu imple- 

15 mentierten und uber ein Eingabemittel , etwa eine Tastatur, zu 
bedienenden Auswahlschalter 2 5 ein Zugriff auch auf einzelne 
Datensatze 7 moglich. So kann ein partielles Download durch 
eine Downloadanf orderung mit der Content- ID eines jeweils ge- 
wunschten Datensatzes 7 (beispielsweise eines Fotos ohne 

20 gleichzeitige Mitttbertragung des Begleittextes ) in WAP mit 
dem Befehl 13: WSP GET.req veranlaftt werden. 

Urn dieses zu ermoglichen, mufi das grundsatzliche Problem ge- 
lost werden, daJ5 die zusatzlichen Header-Felder teilweise in 
25 einer MM mehrfach verwendet werden nuissen (WAP: z.B. X-Mms- 
Content-Name ftir jeden Datensatz 7 der MM) . Stehen mehrere 
Header-Felder in einem inhaltlichen Zusammenhang, was bei der 
Beschreibung eines Datensatzes der Fall ist, mufi auch eine 
syntaktische Zuordnung definiert sein. 

30 

Grundsatzlich ist im WAP-Standard die Reihenfolge der Header- 
Felder unerheblich. Eine Veranderung der Reihenfolge der In- 
formationen Name, Gr6fie, Typ und/oder URI mehrerer Datensatze 
7 wurde damit eine Veranderung bzw. Verfalschung der Be- 
35 schreibungen der Datensatze 7 bewirken, wenn man die Zuord- 
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nung der Inf ormationen von der Reihenfolge der Header- 
Elemente abhangig machte, was der einzig gangbare Weg ist, da 
eine hierarchische Struktur der Header-Elemente in WAP nicht 
vorgesehen ist, 

5 Andererseits steht die Aussage der Irrelevanz der Header- 

Element-Reihenfolge im Widerspruch zu der Aussage, daB HTTP- 
Header, die Listen enthalten, in mehrere WSP-Header mit je- 
weils nur einem einzigen Element umgewandelt werden sollen, 
wobei die Reihenfolge der Eintrage erhalten bleiben soli. Urn 1 
10 diesen Widerspruch aufzulosen, wird eine Systematik entwor- 
fen, die die Signifikanz der Reihenfolge der Header-Elemente 
voraussetzt . 

Zur Abgrenzung der Beschreibungen einzelner Datensatze 7 muft 
15 ein definiertes Header-Feld die Beschreibung eines Datensat- 
zes 7 beginnen, der alle nachf olgenden Header-Felder zugeord- 
net werden, bis entweder das Ende des Headers der Message er- 
reicht ist oder ein nachstes Header-Feld des definierten Typs 
den Beginn der Beschreibung eines weiteren Datensatzes 7 mar- 
20 kiert. 

Als definiertes Header-Feld fur die Beschreibung eines Daten- 
satzes 7 dient das Feld 17: X-Mms-Content-ID, da es die ein- 
deutige Adresse des Elements enthalt. Die Beschreibung eines 
25 Datensatzes 7 wird grundsatzlich durch dieses Feld eingelei- 
tet, worauf die weiteren Felder optional und in beliebiger 
Reihenfolge erscheinen konnen. 

Alternativ zu der Systematik mit eindeutigen Marken fur die 
30 Mess age -Elemente - den Content-IDs - und den entsprechenden 

Verweisen im Header ist auch eine Systematik moglich, die mit 
der Angabe eines Offsets bis zu dem beschriebenen Datensatz 
im Datenteil der MM arbeitet. Nachteilig sind dabei aller- 
dings zum einen die Gefahr, den Offset nicht korrekt zu be- 
35 rechnen bzw. bei einer moglichen Formatkonvertierung im MMS 
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Relay 3 nicht korrekt anzupassen, und zum anderen die fehlen- 
de Moglichkeit, eine logische Beziehung zwischen einer Be- 
schreibung eines Datensatzes 7 in der Benachrichtigung 11 und 
in der tatsachlichen Ubersendung 14 der MM herzustellen. Die 
5 Informationen mufiten dann in der zugestellten Multimedia Mes- 
sage noch einmal enthalten sein. 

Der Versender (Ebene 2) kann an seinem Telekommunikationsge- 
rat 5 eine hardwareseitig oder insbesondere sof twareseitig 

10 und tiber die ohnehin vorhandene Tastatur zu bedienende Einga- 
bemoglichkeit betatigen, um damit in den Header-Feldern 17, 
18, 19, 20, 21, 22, 23 die zusatzlichen Informationen oder 
einen Teil dieser Informationen (s.o.) zu hinterlegen. Diese 
werden als Best'andteil eines Identif izierungssignals fur ei- 

15 nen oder mehrere Datensatze 7 der MM mit der Sendung 9 (in 

WAP: M-Send.req) (Fig. 1) an den Provider (Ebene 3) gesandt. 
Die Bestatigung des Versands durch das MMS-Relay 3 (in WAP 
mit der Nachricht 10: M-Send.conf) bleibt unverandert, da die 
einzige wesentliche Information die optional vom MMS-Relay 3 

20 vergebene Message-ID ist. 

Der Empf anger 4 erhalt dann die Nachricht 11 (in WAP M- 
Notif ication . ind) , dafi fur ihn eine MM mit einem oder mehre- 
ren Datensatzen 7 zum Herunterladen bereitliegt. Diese Be- 

25 nachrichtigung 11 enthalt wiederum alle zusatzlichen Header- 
Felder 17, 18, 19, 20, 21, 22, 23 zur Beschreibung der Daten- 
satze 7 aus dem Header der Nachricht 9 zu ihrem Versenden (in 
WAP: M-Send.req) . Diese Information kann dem Empf anger op- 
tisch (uber das Anzeigemittel 24, beispielsweise das Display) 

30 oder akustisch mitgeteilt werden. 

Die Bestatigung 12 (WAP: M-Notif yResp . ind) des Empfangs der 
Notification 11 bleibt unverandert. 

Nachdem der Empfanger 4 der MM detailliert uber deren Inhalt 
35 informiert ist, kann er die gesamte MM (in WAP: durch das 
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Kommando 13: WSP Get.req) herunterladen. Alternativ ist nach 
dieser Erfindung auch ein Zugriff auf ein elnzelnes Element 
der MM moglich, Hierzu wird beispielweise als URI die Con- 
tent-ID eines Datensatzes 7 der MM in das Kommando zum Down- 
5 load eingesetzt. Ohne Zustimmung des Empf angers 4 wird ein 
Herunterladen der MM (Ubersendung der Sendung 14 an den Emp- 
fanger) nicht freigegeben. Auch ist es moglich, dafi der Emp- 
fanger 4 die MM erst zu einem spateren, billigeren Zeitpunkt 
tibermittelt bekommen will. 

10 

Die eigentliche Datensendung 14 kann die beschreibenden Hea- 
der-Felder 17, 18, 19, 20, 21, 22, 23 enthalten. Dies ist je- 
doch nicht zwingend , wie in Fig. 7 dargestellt. 

15 SchlieJilich schickt das MMS-Relay 3, wenn vom Versender 2 ge- 
wtinscht, eine Mitteilung 16 iiber den Status der Zustellung 
der MM (in WAP: M-Delivery . ind) an diesen. Neben den bisher 
schon bekannten Moglichkeiten "Expired" (verfallen) , ^Retrie- 
ved" (zugestellt) , ^Rejected" (abgelehnt) , *Deffered" (verzo- 

20 gert)" kann erf indungsgemafi auch "Partly-retrieved" (partiell 
zugestellt) im Statusfeld auftreten. Es wird angezeigt, wel- 
cher Datensatz 7 zugestellt wurde . Der entsprechende Ab- 
schnitt der Nachricht 16 konnte wie folgt lauten: 

25 »»> 

7.2.22 Status field (Status-Feld) 

Status-value = Expired | Retrieved | Rejected | Deferred | Partly-retrieved 
Expired = <Octet 128> 
Retrieved = <Octet 129> 
3 0 Rejected = <Octet 1 30> 
Deferred = <Octet 131> 
Partly-retrieved = <Octet 132> 
««< 

Die ebenfalls neuen Felder 22, 23 
35 X-Mms-External-Link-Flag (optional) und 
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X-Mms-External-Link-Size (optional) 

konnen in den Nachrichten 9 zum Versand der MM (WAP: M- 
Send.req) und in der Nachricht 11 an den Empf anger 4 (WAP: M- 
Notification.ind) die im Inhalt der MM enthaltenen Links auf 
5 Inhalte aufierhalb der MM anzeigen. Je nach Position im MM 

Header zeigt das Feld 22: X-Mms-External-Link-Flag einen Link 
auf externe Inhalte innerhalb der gesamten MM oder innerhalb 
eines bestimmten Datensatzes 7 der MM an. Das Feld 23: X-Mms- 
External-Link-Size beschreibt optional die Grofie des Inhalts 
10 in Octets. Damit kann der Empf anger der Notification bereits 
abschatzen, welches zusatzliche Datenvolumen zu dem der MM 
selbst noch herunterzuladen ist. 

Das vorgestellte Verfahren kann in eine Software zum Betrei- 
15 ben des jeweiligen Kommunikationsstandards, etwa UMTS, integ- 
riert sein. Die Telekommunikationsgerate 5, 6 sind dann mit 
einer entsprechenden Software versehen. 

Im folgenden ist ein konkreter Ablauf der erf indungsgemalien 
20 Ubermittlung einer MM nach dem WAP-Standard (Fig. 1) darge- 
stellt: 

Es wird beispielhaft folgendes Szenario angenommen: Versender 
2 (Markus Trauberg) verschickt eine MM mit einem Text mit 

25 mehreren Datensatzen 7, namlich einem MP3-Audio, einem JPEG- 
Bild, einem MPEG-4-Video und einer SMIL-Prasentationsbe- 
schreibung, an zwei Empfanger 4 (Andreas Schmidt und Josef 
Laumen) . Zur komfortablen und dif f erenzierten Nutzung durch 
die Empfanger 4 fugt er Beschreibungen von Parametern der Da- 

30 tensatze 7 der MM ihrem Header bei. Die Daten werden in den 

Nachrichten 9 (M-Send.req) und 11 (M-Notif ication . ind) an die 
Empfanger ubertragen. Empfanger 4 Andreas Schmidt ladt die 
komplette MM auf sein Endgerat 6, wahrend Empfanger 4 Josef 
Laumen nur an dem Text interessiert ist und nur diesen auf 
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sein Endgerat 6 ladt. Die folgenden MMs werden zwischen den 
Einheiten tibertragen: 

MM wird an zwei Adressaten verschickt. Dann kann das Nach- 
5 richtenprotokoll wie in Figur 9 abgebildet sein. 

In der MM sind im Header die zusatzlichen Inf ormationsblocke 
ilber die MM-Elemente codiert. Darin werden auch die Beziehun- 
gen zwischen den Datensatzen 7 der MM beschrieben: So enthalt 

10 die Beschreibung der presentationjiescription Verweise auf 
die darin externen Elemente image/jpeg, audio/mp3 und vi- 
deo/mpeg4 in Form der entsprechenden Content-IDs. 
Die Beschreibung des Textes enthalt die Information, daB ein 
Verweis auf ein externes Objekt enthalten ist, das 8245 Byte 

15 Daten umfaftt. 

Die Quittierung der oben aufgeftihrten Sendeanfrage 9 (M- 
Send.req) des Versenders 2 erfolgt mit der Nachricht 10 (M- 
Send.conf) vom MMS Relay 3. Diese Nachricht 10 enthalt keine 
20 zusatzlichen neuen Felder, wie an ihrer folgenden Aufstellung 
sichtbar ist, die in Figur 10 abgebildet ist. 

Das MMS Relay 3 bestatigt mit Nachricht 10, daB die Anfrage 9 
fehlerfrei zum MMS Relay 3 tibertragen worden ist. Es wird die 

25 Transaction-ID#l benutzt, um die Nachricht 10 beim Versender 
2 eindeutig der dazugehorigen Anfrage 9 (M-Send.req) und da- 
mit der gesendeten MM zuzuordnen. Weil in der Nachricht 9 in 
dem Feld X-Mms-Delivery-Report ein Zustellungsreport angefor- 
dert wurde, weist das MMS Relay 3 der MM eine Message-ID zu 

30 und ubermittelt diese hier an den Versender 2 . 

Im weiteren wird die Nachricht 11 an die Empfanger 4 tibertra- 
gen: 



M-Notif ication. ind (MMS Relay MMS User Agent B) 
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Im MMS ist vorgesehen, einen Empfanger einer MM tiber neue 
Nachrichten, die fUr ihn vorliegen, zu inf ormieren. Die Nach- 
richt 11 (M-Notification.ind) dient der Benachrichtigung der 
5 Adressaten tiber zum Download bereitliegende MM. Folglich e- 
xistieren in diesem Beispiel zwei Benachrichtigungen an die 
Empfanger Andreas Schmidt und Josef Laumen. Jede enthalt eine 
eigene Transaction-ID. Die Information tiber den Speicherplatz 
der MM steht bei beiden in dem Feld X-Mms-Content-Location . 

10 

Figur 11 gibt den Inhalt der M-Notif ication-ind exemplar isch 
wieder . 

Neben den tiblichen Feldern zu Beginn der Nachricht 11 konnen 
15 nun alle beschreibenden Elemente der Nachricht 9 in die Nach- 
richt 11 tibernommen werden. Zusatzlich werden, wie oben an- 
hand der Mischform beschrieben, durch das MMS Relay 3 noch 
die Inf ormationen X-Mms-Content-Type und X-Mms-Content-Size 
aus den Inf ormationen des Body der Nachricht 9 generiert. Der 
20 Empfanger 4 kennt nach Erhalt der Nachricht 11 sowohl die Ad- 
resse der MM (wie bisher) als auch die Zusammensetzung aus 
den einzelnen Datensatzen 7 und deren Content-IDs. Ein 
Zugriff ist daher auch separat auf einzelne Datensatze 7 der 
MM moglich. 

25 

Der korrekte Empfang der Benachrichtigung wird anschlieflend 
von dem Empfanger 4 der MM mit der Nachricht 12 (M- 
Notif yResp. ind) bestatigt, indem die entsprechende Transacti- 
on-ID der Nachricht 11 zusammen mit einer Statusmeldung zu- 
30 rtick zum MMS Relay 3 geschickt wird. 



Der Download der MM wird durch das Kommando 13 (WSP GET.req) 
veranlaJit. Die MM wird darauf vom MMS Relay 3 in der Nach- 
richt 14 (M-Retrieve.conf ) zum Empfanger 4 gesendet. 
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Da die Inf ormationen iiber die einzelnen Elemente bereits mit 
der Nachricht 11 ubertragen wurden, kann der Download der ge- 
samten MM wie bisher mit der Nachricht 14 erfolgen, ohne dafi 
zusatzliche Felder im Header dieser Nachricht 14 eingefugt 
werden mussen. Die zusatzlichen Inf ormationen in den Headern 
der einzelnen Datensatze 7 hingegen sollten auch in der Nach- 
richt 14 enthalten sein, da sie wichtige Inf ormationen uber 
die MM-Datens&tze 7 enthalten. 

Im folgenden sind zwei mogliche Reaktionen der Empfanger 4 
beispielhaft dargestellt: 

Empfanger Andreas Schmidt ladt die gesamte MM. 

Empfanger Josef Laumen ladt nur den Textteil der MM auf sein 

Empf angsgerat 6. 

Im ersten Fall wird die Nachricht 14 wie in Figur 12 abgebil- 
det codiert: 

Der Empfanger 4 Andreas Schmidt quittiert den erf olgreichen 
Empfang der MM anschlieflend Nachricht 15 (M- Acknowledge . ind) . 
Mit der darin enthaltenen Transaction-ID ist am MMS Relay 3 
die Zuordnung zu der gesendeten MM entsprechend dem Informa- 
tionssignal M-Acknowl edge . ind von Figur 13 moglich. 

Als letzter Schritt der Transaktion wird schliefilich die 
Nachricht 16 (M-Delivery . ind) entsprechend Figur 14' vom MMS 
Relay 3 an den Versender 2 Ubermittelt: 

Der zweite Empfanger Josef Laumen hingegen entscheidet sich 
dafUr, nur den Textteil der Nachricht 14 zu laden. Dazu setzt 
er in die Nachricht 13 (WSP GET.req) die Conteht-ID des Text- 
teils ein: " 000714 . 1412 . Imarkus . trauberg" . Er erhalt diesen 
Textteil mit der Nachricht 14 (M-Retrieve . conf ) , die gegen- 
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uber der Version an Andreas Schmidt deutlich verandert ist 
und deren Inhalt in Figur 15 exemplarisch wiedergegeben ist. 

Die Nachricht 14 wurde gegeniiber ihrer kompletten Version, 
5 wie sie an Andreas Schmidt geschickt wurde, um die nicht er- 
wunschten Datensatze 7 reduziert. Auflerdem wurde das Feld 
nEntries entsprechend angepallt. 

Die Nachricht 15 (M-Ac knowledge . ind) , die in Figur 16 darge- 
10 stellt ist, entspricht fast komplett der Version an Andreas 
Schmidt, enthalt aber eine eigene Transaction-ID: 

Als letzter Schritt erfolgt wieder die Benachrichtigung des 
Versenders 2 liber den Status der Zustellung. Sie enthalt den 
15 Status der partiellen Zustellung (" Partly-retrieved" ) und ist 
inhaltlich in Figur 17 dargestellt. 

Neben den vorstehend beschriebenen Moglichkeiten zur detail- 
lierten Benachrichtigung von Empfangern von Multimedia Nach- 
20 richten (MMs) im Multimedia Messaging Service (MMS) besteht 
eine weitere, zweckmaliige Option, die Vorteile gegeniiber den 
bereits vorgestellten Varianten hat. Diese vorteilhafte Opti- 
on wird nachfolgend beschrieben. 

25 Kern dieser Modifikation ist die Realisierung der Idee, den 
jeweiligen Empf anger detailliert iiber den Inhalt der jeweili- 
gen MM zu inf ormieren, wobei lediglich ein einziges, neu de- 
finiertes Header-Feld genutzt wird, fur das neue Parameter 
eingefiihrt werden. Das neue Header-Feld enthalt dabei alle 

30 Parameter, d.h. Inf ormationen Uber ein zu beschreibendes Ele- 
ment der MM. Unter Element bzw. Datensatz einer MM wird in 
dieser Erf indungsmeldung ein einzelner Bestandteil einer MM 
verstanden, der insbesondere durch seinen Typ (z.B. Stand- 
bild) und sein Format (z.B. JPEG (= joint photographies ex- 

35 pert group)) definiert ist. 
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Die folgende Liste enthalt die bereits zu den vorausgehenden 
Varianten vorgeschlagenen Inf ormationen, die dem Empfanger 
einer MM optional in einer Empf angerbenachrichtigung im MMS 
(M-Nind; in WAP: M-Notif ication. ind) zur Verfugung gestellt 
werden konnen. Dazu gehoren: 

• die Anzahl der enthaltenen Elemente der MM (auch implizit 
durch die Beschreibung der einzelnen Elemente der MM) , 

• die Grofie (in Octets) eines Elements, 

• der Typ und das Format eines Elements, 

• die Content ID (Content IDentif ication) eines Elements (= 
Name bzw. Bezeichner des jeweiligen Headerfeldes des je- 
weiligen Identif ikationssignals ) , 

• der Name eines Elements, 

• die Verbindung eines Elements zu einem Oder mehreren ande- 
ren Elementen der MM, 

• die Verbindung der gesamten MM Oder eines/mehrerer Elemen- 
te zu einer oder mehreren URLs/URIs (uniform resource 
link/identifier) aufierhalb der MM und bei einem solchen 
externen Bezug optional die Grofie der zu ladenden Objekte 
des/der aufgelosten externen Bezuge. 

Die Definition der entsprechenden Header-Felder zur optiona- 
len Erweiterung der MMS Empf angerbenachrichtigung (M-Nind; in 
WAP: M-Notif ication. ind) und gegebenenf alls auch der MMS Sen- 
deanfrage (M-Sreq; in WAP: M-Send. req) und der MMS- 
Zustellnachricht (M-Rconf; in WAP: M-Retrieve. conf) sind im 
beim nachf olgehden Ausf uhrungsbeispiel beschrieben. 

Eine MM besteht grundsatzlich - wie in den vorausgehenden 
Ausfuhrungsbeispielen aufgezeigt - aus einem Header und ab- 
hangig vom Typ der Nachricht ggf . zusatzlich aus einem Daten- 
teil (WAP: Body) . Der Header umfasst allgemeine Inf ormationen 
der Nachricht und setzt sich aus ein oder mehreren, definier- 
ten Header-Feldern zusammen. Der etwaige Datenteil der Messa- 
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ge enthalt ein Oder mehrere Elemente beliebigen Typs, die in 
beliebiger Reihenf olge dem Header folgen. Falls eine Prasen- 
tationsbeschreibung im Datenteil enthalten ist, soil z.B. in 
einer WAP-Nachricht zu Beginn des Datenteils ein so genannter 
5 Start-Parameter auf diese Prasentationsbeschreibung zweckma- 
Bigerweise hinweisen. 

Figur 1 zeigt dabei in einem Nachrichtenf lussdiagram den 
prinzipiellen Ablauf einer Nachrichteniibermittlung von der 
10 Nutzerapplikation des sendenden Nutzers 2 (User Agent A = M- 
UA_A) iiber die MMS Verbindungseinheit 3 (MMS Relay=M-SR) zur 
Nutzerapplikation des empf angenden Nutzers 4 (User Agent B 
= (M-UA_B) ) . 

15 Die je nach Nachrichten-Typ moglichen bzw. erf orderlichen 

Header-Felder in WAP sind ftir die hier betrachteten Nachrich- 
ten-Typen in den Tabellen entsprechend der Figuren 21 A/21B 
und 22 dargestellt. Diese wurden WAP-209-MMSEncapsulation, 
Release 2000; Wireless Application Protocol; WAP Multimedia 

20 Messaging Service; Message Encapsulation; MMS Proposed SCD 

1.0 entnommen. Nach WAP-203-WSP, Version 4-May-2000; Wireless 
Application Protocol, Wireless Session Protocol Specificati- 
on; Chapter 8.4: "Header Encoding" besteht jedes Header-Feld 
aus einem Feld-Namen, gefolgt von einem Feld-Wert, der aus 

25 mindestens einem Octet besteht. Die Zuweisung von hexadezima- 
len Werten zu den Feld-Namen der WAP Messages ist in der Ta- 
belle entsprechend Figur 20 aufgefuhrt. 

Diese weitere Option beruht auf der zu den vorausgehenden 
Ausfiihrungsbeispielen eingefiihrten Definition eines Header- 
30 Feldes zur eindeutigen Kennzeichnung eines Elementes einer 
MM, dem Header-Feld X-Mms-Content- ID, das im Body der MM dem 
Element der MM als Header-Feld voransteht und das Element 
eindeutig kennzeichnet . 
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Abweichend von den vorausgegangenen Vorschlagen basiert die 
Beschreibung eines Elementes der MM hier auf einem einzigen 
Header-Feld X-Mms-Content-ID, das in den Header der MM zur 
Benachrichtigung des Empfangers integriert wird, und das die 
notigen Inf ormationen (ftlr die Benachrichtigung des Empfan- 
gers z.B. fiber Anzahl, Typ, Grofle, Format der fUr ihn bereit- 
gehaltenen Datensatze der MM) durch einen Oder mehrere Para- 
meter aus der folgenden Liste beschreibt. 

• Name beschreibt den Namen des MM-Elements; 

• Type beschreibt den Typ und das Format des MM-Elements; 

• Size beschreibt die Grofie des MM-Elements in Bytes; 

• External-Link zeigt an, dass das Element eine Verknupfung 
auf Inhalte aufierhalb der MM enthalt; 

• External -Link-Size gibt an, welches Datenvolumen zum Auf- 
losen der externen Referenz zusatzlich heruntergladen wer- 
den mufi; 

• Related-ID gibt an, welches Element der MM mit dem Ele- 
ment in Bezug steht und bei einem partiellen Herunteralden 
der MM ebenfalls geladen werden sollte (Mehrf achverwendung 
moglich. 

Allgemein ausgedruckt wird also jetzt das Identif ikationssig- 
nal fur einen oder mehrere zugeordnete Datensatze in einem 
einzigen, zusatzlichen Headerfeld vom jeweiligen Sender wie 
z.B. einem ersten Mobilf unkgerat und/oder zustandigen Server 
in einer MMS Empf angerbenachrichtigung zum Empf anger wie z.B. 
zu einem zweiten Mobilf unkgerat codiert ubertragen. Dadurch 
sind Reihenfolgen- und Zuordnungsprobleme, wie sie etwaig bei 
der Verwendung mehrerer Headerfelder zwischen diesen selbst 
und/oder den zugeordneten Datensatzen auftreten konnten, von 
vornherein vermieden. 
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Weiterhin sollen zusatzlich zu den bereits zu den vorausge- 
henden Ausfuhrungsbeispielen beschriebenen auch folgende In- 
formationen als Parameter codiert werden konnen: 

1. Original-Type beschreibt den Typ des MM-Elements vor 
5 der Transcodierung durch die MMS Verbindungseinheit (M- 

SR) ; 

2. Original-Size beschreibt die Grofie des MM-Elements vor 
der Transcodierung durch die MMS Verbindungseinheit (M- 
SR) in Bytes; 

10 

Durch die Zusammenf assung aller fur ein MM-Element relevanten 
Informationen in einem einzigen Header-Feld, kann auf eine 
Einhaltung der Header-Reihenf olge, wie sie bei den vorherge- 
henden Ausfuhrungsbeispielen vorausgesetzt wird, verzichtet 
15 werden. 

In Figur 18 ist das zum Zwecke der detaillierten Benachrich- 
tigung des Empf angers einer MM gemaJJ WAP neu eingefuhrte, 
einzige Header-Feld einschlieiilich der Codierung von Feld- 

20 Name und Feld-Wert aufgefiihrt. Die Tabelle entsprechend Figur 
2 0 enthalt die Zuweisung von hexadezimalen Werten zu den 
Feld-Namen. Die Tabelle entsprechend Figur 19 enthalt die Zu- 
weisung von hexadezimalen Werten zu den Parameternamen und 
weiterhin die zur Codierung der Parameterwerte zu verwenden- 

25 den Typen. Die urn die entsprechenden Header-Felder erganzten 
WAP Nachrichten sind in den Tabellen 21A/21B und 22 aufgelis- 
tet. Alle Veranderungen und Erganzungen in den Tabellen zum 
heutigen Stand der Technik sind dabei eingerahmt. 

30 Ausftihrungsbeispiel : 

Im nun folgenden Ausftihrungsbeispiel, das auf der Definition 
der beschriebenen Nachrichten durch das WAP-Forum basiert, 
wird detailliert auf die in den WAP Nachrichten benutzten 
Header-Felder eingegangen. Dabei wird beispielhaft folgendes 

35 Szenario angenommen: M-UA__A (Markus Trauberg) verschickt eine 
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Multimedia Message MM A bestehend aus einem Text, einem MP3- 
Audio, einem JPEG-Bild, einem MPEG-4-Video und einer SMIL 
(synchronized multimedia integration language) - 

Prasentationsbeschreibung an einen Empf anger M-UA__B (Andreas 
5 Schmidt) . Zur komfortablen und dif f erenzierten Nutzung durch 
den Empfanger werden Beschreibungen der Elemente der MM dem 
Header der MM gemaB dieser Erf indungsmeldung zugeftigt. Die 
Daten werden in den Nachrichten M-Sreq und M-Nind an den Emp- 
fanger tibertragen. Empfanger Andreas Schmidt ladt die kom- 
10 plette MM auf sein Endgerat. Die folgenden Nachrichten werden 
zwischen den Einheiten tibertragen. 

MM A wird an einen Adressaten verschickt. Deren Inhalt ist in 
Figur 23 beispielhaft abgebildet. 

15 

In der Message sind im Header die zusatzlichen Inf ormations- 
blocke, d.h. allgemein ausgedruckt die ein oder mehreren Pa- 
rameter Uber die MM-Elemente codiert. Darin werden auch die 
Beziehungen zwischen den Elementen der MM beschrieben: So 
20 enthalt die Beschreibung der Prasentationsbeschreibung 
(*.smil) Verweise auf die darin ref erenzierten Elemente 
image/jpeg, audio/mp3 und video/mpeg4 in Form der entspre- 
chenden Content-IDs. 

Die Beschreibung des Textes enthalt die Information, dass ein 
25 Verweis auf ein externes Objekt enthalten ist, das 8245 Byte 
Daten umfasst, 

Nach dem Stand der Technik wird die Sendeanfrage (WAP: M- 
Send.req) des MMS User Agent A mit einer Nachricht (in WAP:M- 
30 Send, conf) vom M-SR quittiert. Im Rahmen dieser EM wird diese 
Message nicht modifiziert und daher hier nicht aufgeftihrt. 



M-Nind (M-SR -> M-UA-B) 
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Im MMS (multimedia services) entsprechend 3G TS 23.140 versi- 
on 3.0.1, Release 1999; Third Generation Partnership Project; 
Technical Specification Group Terminals; Multimedia Messaging 
Service (MMS) ; Functional Description; Stage 2 und WAP-209- 
5 MMSEncapsulation, Release 2000; Wireless Application Proto- 
col; WAP Multimedia Messaging Service; Message Encapsulation; 
MMS Proposed SCD 1.0 ist vorgesehen, einen Empf anger einer MM 
uber neue Nachrichten, die fur ihn vorliegen, zu informieren. 
Die Nachricht M-Nind (in WAP: M-Notification. ind) dient der 

10 Benachrichtigung der Adressaten uber zum Herunterladen be- 

reitliegende MMs . Ihr Inhalt ist beispielhaft in Figur 24 ab- 
gebildet. Folglich existiert in diesem Beispiel eine Empfan- 
gerbenachrichtigung an den Empf anger Andreas Schmidt. Die In- 
formation uber den Speicherplatz der MM A steht dabei in dem 

15 Feld X-Mms-Content-Location. 

Neben den tiblichen Feldern zu Beginn der Nachricht konnen nun 
alle beschreibenden, nach dieser Variante neuen Elemente der 
Nachricht M-Sreq in die Nachricht M-Nind Obernommen werden. 
Zusatzlich werden durch die M-SR noch die Inf ormationen Type 
und Size aus den Inf ormationen des Body der Nachricht M-Sreq 
generiert bzw. wird das enthaltene Bild vom Typ image/ jpeg in 
den Typ image/bmp konvertiert, da das Endgerat JPEG-Bilder 
nicht anzeigen kann. Die entsprechenden Inf ormationen tiber 
den ursprtinglichen Typ (Original-Type) und die ursprungliche 
Dateigrofie (Original-Size) sind im entsprechenden Header-Feld 
erganzt worden. Der Empf anger kennt nach Erhalt der detailed 
Notification sowohl die Adresse der MM (wie bisher) als auch 
die Zusammensetzung aus den einzelnen Elementen und deren 
Content-IDs. Ein Zugriff ist daher auch separat auf einzelne 
Elemente der MM moglich. 

Der korrekte Empfang der Benachrichtigung kann anschliefiend 
von dem Empfanger der MM A mit der Nachricht M-NRind bestatigt 
35 werden, indem die entsprechende Transaction-ID der M-Nind zu- 
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sammen mit einer Statusmeldung zuriick zum MMS Relay geschickt 
wird. Dann wird das Herunterladen der MM A durch den Befehl W- 
Greq veranlasst. Die MM wird darauf vom M-SR in der Nachricht 
M-Rconf zum MM-UA A gesendet. 

5 

Im Folgenden wird die Nachricht von dem Empfanger Andreas 
Schmidt komplett auf sein Endgerat he'runtergeladen. Die Nach- 
richt M-Rconf wird beispielsweise wie in Figur 25 codiert. 

10 Der Empfanger M-UA B quittiert den erf olgreichen Empfang der 
MM A anschliefiend gemali Stand der Technik mit der Nachricht 

Zusammenf assend betrachtet wird somit ein Verfahren zur tTber- 
tragung zusatzlicher Inf ormationen zur detaillierten Be- 

15 schreibung einer Multimedianachricht und der darin enthalte- 
nen MM-Elemente im Multimedia-Messaging-Service (MMS) bereit- 
gestellt. Diese Inf ormationen werden insbesondere mit einem 
einzigen oder mehreren zusatzlichen Header-Feldern in der je- 
weiligen MMS Empf angerbenachrichtigung vom jeweilig zustandi- 

20 gen Server wie z.B. M-SR zum empfangenden User Agent iibertra- 
gen. Die notigen Inf ormationen werden vorzugsweise vom sen- 
denden User Agent generiert und in der MMS Sendeanfrage von 
diesem codiert zum zustandigen Server ttbertragen. Zusatzlich 
oder unabhangig hiervon kSnnen die notigen Inf ormationen auch 

25 vom zustandigen Vermittlungs-/Bereitstellungs-Server aus dem 
Datenteil der jeweilig zu versendenden MM extrahiert und dem 
Empfangenden User Agent in der MMS Empf angerbenachrichtigung 
codiert ubertragen werden. Vorzugsweise kann dem empfangenden 
User Agent eine oder mehrere der folgenden Inf ormationen liber 

30 den Inhalt oder einzelne Elemente des Inhalts der zur Zustel- 
lung z.B. im zustandigen Server bereitliegenden Nachricht 
mitgeteilt werden: 

• Anzahl der in der MM enthaltenen Elemente 

• Grofte des Elements der MM (in Octets) 
35 • Typ und Format des Elements der MM 
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• Kennzeichnung des Elements (Content-ID bzw. URI) 

• Name des Elements 

• die Verbindung eines oder mehrerer Elemente zu einem o- 
der mehreren anderen Element en innerhalb der MM (z*B. 
zwischen Prasentationsbeschreibung und Prasentations- 
element ) 

• die Verbindung eines oder mehrerer Elemente zu Inhalten 
beliebiger Natur auflerhalb der MM (z.B. zu HTML/ WML - 
Seiten) 

• die jeweilige GroJJe der verkniipften externen Elemente, 
die zusatzlich zur MM selbst geladen werden kQnnen (in 
Octets) 

• der Typ und das Format des Elements vor einer Transco- 
dierung durch die M-SR 

• die Grofie des Elements vor einer Transcodierung durch 
die M-SR (in Octets) 

Insbesondere bildet dabei die Kennzeichnung des Elements 
(Content -ID bzw. URI) den ersten Eintrag im einzigen Header- 
feld oder den Inhalt des ersten Headerfeldes bei mehreren be- 
nutzten Headerf eldern pro Element bzw. Datensatz. 

Bevorzugt kann die Beschreibung eines Elements einer MM je- 
weils mit einem einzigen Feld ausgeftihrt werden, das per ein- 
deutiger Identif ikationsnummer bzw. Bezeichner auf das Ele- 
ment im Datenteil der Multimedianachricht verweist, und das 
die weiteren Inf ormationen als Parameter auch noch und nicht 
in separaten Headerf eldern enthalt. 

Der Empfanger einer MM kann vorzugsweise, nachdem er eine de- 
taillierte Benachrichtigung erhalten hat, auch nur einzelne 
Elemente der MM auf sein Endgerat laden. Genauso ist es ggf . 
moglich, dass die nach dieser Erfindung zusatzlichen Informa- 
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tionen der MMS Empf angerbenachrichtigung (M-Nind) auch im 
Header der MMS Zustellnachricht (M-Rconf) erganzt werden. 

Vorzugsweise kann das zusatzliche Header-Felder - wenn nur 
5 ein einziges Headerfeld pro Datensatz verwendet wird - in WAP 
wie folgt codiert werden: 

Codierung des Feld-Namens X-Mms-Content-ID im Wertebereich 
zwischen 00X00 bis 0X7F, insbesondere als 0x19 gemafi der Ta- 
belle nach Figur 20, 
10 Codierung des Feld-Wertes von X-Mms-Content-ID gemafi Figur 9. 

Die Informationen als Parameter in diesem einzigen Header- 
Feld konnen insbesondere nach der Tabelle von Figur 19 co- 
diert werden. 

15 

Hintergrundangaben zu WAP und MMS, insbesondere zu deren ein- 
schlagiger Normenliteratur finden sich beispielsweise an fol- 
genden Stellen: 

[1] 3G TS 23.140 version 3.0.1, Release 1999; Third Ge- 

20 neration Partnership Project; Technical Specifica- 



25 



30 



[4] 



[2] 



[3] 



tion Group Terminals; Multimedia Messaging Service 
(MMS ) ; Functional Description; Stage 2 
WAP-209-MMSEncapsulation, Release 2000; Wireless 
Application Protocol; WAP Multimedia Messaging Ser- 
vice; Message Encapsulation; MMS Proposed SCD 1.0 
WAP-2 03-WSP, Version 4-May-2000; Wireless Applica- 
tion Protocol, Wireless Session Protocol Specifica- 
tion; Chapter 8.4: "Header Encoding' 7 . 
WAP- Forum:" WAP MMS Interworking with Internet E- 
mail; WAP-2 07-Mmslnetlnterworking" ; Draft Version 
Ol-Jun-2000. 



[5] 



3G TS 22.140 v. 4. 0.1 (Juli 2000) : 3rd Generation 
Partnership Project; Technical Specification Group 
Services and System Aspects; Service Aspects; Stage 
1 Multimedia Messaging Service. 
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[6] RFC822: "Standard for the Format of ARPA Internet 

Text Messages", Crocker D., August 1982. URL: 
ftp ; //ftp . isi . edu/in-notes/rf c822 . txt . 
[7] RFC2045: "Multipurpose Internet Mail Extensions 

5 (MIME) Part One: Format of Internet Message Bo- 

dies", Freed N., November 1996. 
URL : ftp : //ftp . isi . edu/in-notes/rf c2 04 5 . txt . 
[8] RFC204 6: "Multipurpose Internet Mail Extensions 

(MIME) Part Two: Media Types", Freed N., November 
10 1996. URL: ftp : //ftp . isi . edu/in-notes/rf c2 04 6 . txt • 

[9] RFC2047: "MIME (Multipurpose Internet Mail Extensi- 

ons) Part Three: Message Header Extensions for Non- 
ASCII Text", Moore K., November 1996. URL: 
ftp : //ftp. isi . edu/in-notes/rf c2 04 7 .txt . 

15 Im Rahmen der Erf indungsbeschreibung ist der einfacheren 

Schreibweise halber im Kontext auf folgende, gangigen Akrony- 
me Bezug genoramen wurden, die zum besseren Verstandnis mit 
ihrer vollstandigen Bedeutung nachfolgend aufgelistet sind: 

20 GSM Global System for Mobile Communication 

MM Multimedianachricht (Multimedia Message) 

MMS Multimedia Messaging Service 

SMS Short Message Service 

UMTS Universal Mobile Telecommunication System 

25 WAP Wireless Application Protocol 

WSP Wireless Session Protocol 

MMS spezifische AbkUrzungen: 

3 0 M-UA MMS Nutzer Applikation 

M-SR MMS Verbindungseinheit 

M-Sreq MMS Sendeanfrage 

M-Sconf MMS Sendebestatigung 

M-Nind MMS Empf angerbenachrichtigung 

3 5 M-NRind MMS Empf angerbenachrichtigungsbes tat igung 
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W-Greq MMS Zustellanf rage 
M-Rconf MMS Zustellnachricht 
M-Aind MMS Zustellungsbestatigung 
M-Dind MMS Zustellstatusbenachrichtigung 
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Patentanspriiche 

1. Verfahren zur Datenttbertragung in einem Mobilf unknetz, 
insbesondere von Text- und/oder Bilddaten mit und ohne Ton, 

5 dadurch gekennzeichnet, 

daft den Daten zumindest ein Identif ikationssignal fur einen 
Datensatz oder mehrere Datensatze zugeordnet und dieses oder 
diese Identif ikationssignal (e) an den Empf anger der Daten tt- 
bertragen wird oder werden. 

10 ' 

2. Verfahren nach Anspruch 1, 
dadurch gekennzeichnet, 

daft das oder die Identif ikationssignal (e) vor "Obertragung des 
oder der durch diese (s) charakterisierten Datensatzes oder 
15 Datensatze ubertragen wird und optisch oder akustisch anzeig- 
bar ist. 

■. 

3. Verfahren nach Anspruch 2, 
dadurch- gekennzeichnet, 

20 daft der Empfanger des oder der Identif ikationssignal (e) aus- 
wahlen kann, ob er die Ubertragung der durch diese charakte- 
risierten Daten ganz oder teilweise zulaftt. 

4. Verfahren nach einem der Ansprttche 1 bis 3, 
25 dadurch gekennzeichnet, 

daft ein Identif ikationssignal Information ttber die Art eines 
Datensatzes, insbesondere dessen Datenf ormat, enthalt. 

5. Verfahren nach einem der Ansprttche 1 bis 4, 
30 dadurch gekennzeichnet, 

daft ein Identif ikationssignal Information liber den Namen ei- 
nes Datensatzes enthalt. 

6. Verfahren nach einem der Ansprttche 1 bis 5, 
35 dadurch gekennzeichnet, 
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daB ein I dent if ikationssignal Information tiber den Inhalt ei- 
nes Datensatzes enthalt. 

7. Verfahren nach einem der Ansprtiche 1 bis 6, 
5 dadurch gekennzeichnet, 

dafi ein Identif ikationssignal Information uber die Grofie ei- 
nes Datensatzes enthalt. 



8. Verfahren nach einem der Ansprtiche 1 bis 7, 
10 dadurch gekennzeichnet, 

dafi ein Identif ikationssignal Information uber die Anzahl von 
Datensatzen innerhalb von tibertragenen Daten enthalt. 

9. Verfahren nach einem der Ansprtiche 1 bis 8, 
15 dadurch gekennzeichnet, 

dafi ein Identif ikationssignal Information tiber eine Verkntip- 
fung mit zumindest einem Datensatz innerhalb der gesendeten 
Daten enthalt. 



20 10. Verfahren nach einem der Anspriiche 1 bis 9, 
dadurch gekennzeichnet, 

dafi ein Identif ikationssignal Information tiber eine Verkntip- 
fung mit zumindest einem Datensatz aufierhalb der gesendeten 
Daten enthalt. 

25 

11. Verfahren nach einem der Ansprtiche 9 oder 10, 
dadurch gekennzeichnet, 

dafi das Identif ikationssignal Information tiber die Grofie des~ 
jenigen Datensatzes oder derjenigen Datensatze, mit denen ein 
30 ubertragener Datensatz verkntipft ist, enthalt. 



12. Verfahren nach einem der Ansprtiche 1 bis 11, 
dadurch gekennzeichnet, 

dafi ein Identif ikationssignal Information tiber die Kennzeich- 
35 nung eines Datensatzes enthalt. 



WO 02/058359 PCTYEP01/14617 

36 

13, Verfahren nach einem der Ansprtiche 1 bis 12, 
dadurch gekennzeichnet, 

daJi das Verfahren im Mobile Messaging Service (MMS) angewandt 
wird und die tibertragenen Daten als Mobile Messages (MM) aus- 
5 gebildet sind. 

14. Verfahren nach einem der Ansprtiche 1 bis 13, 
dadurch gekennzeichnet, 

daJ5 das Verfahren im tJbertragungsstandard UMTS (Universal Mo- 
10 bile Telecommunication System) , im GSM (Global system for mo- 
bile communication) , im GPRS (General packet radio service) 
und/oder im EDGE (Enhanced Data Rates for GSM enviroments an- 
gewandt wird. 

15 15. Verfahren nach einem der Ansprtiche 1 bis 14, 

•- dadurch gekennzeichnet, 

daii das oder die Identif ikationssignal (e) einem oder mehreren 
Header-Feldern der tibertragenen Daten zugeordnet wird oder 
we r den. 

20 

16. Verfahren nach einem der Ansprtiche 1 bis 15, 
dadurch gekennzeichnet, 

daii ein Identif kationssignal in zumindest einem zusatzlichen 
Header-Feld abgelegt wird. 

25 

17. Verfahren nach einem der Ansprtiche 1 bis 16, 
dadurch gekennzeichnet, 

dafl das oder die Identif izierungssignal (e) zumindest teilwei- 
se vom Versender generiert und bei Obermittlung einer Multi- 
30 media message vom Versender (MMS user agent A) zum Service 
Provider (MMS relay) iibersandt werden. 

18. Verfahren nach Anspruch 17, 
dadurch gekennzeichnet, 

35 dafl der Versender eines oder mehrere der Header-Felder, X- 
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MMS-Content-ID, X-MMS -Content-Name, X-MMS-Content-Type, X- 
MMS-External-Link-Flag, X-MMS-External-Link-Size' generiert. 

19. Verfahren nach einem der Anspruche 1 bis 18, 
5 dadurch gekennzeichnet, 

daii das oder die Identif izierungssignal (e) zumindest teilwei- 
se aus dem vom Service Provider (MMS Relay) empfangenen Da- 
tensatz selbstandig ermittelt wird oder werden 

10 20. Verfahren nach Anspruch 19, 

dadurch gekennzeichnet, 

dafi das MMS Relay eines oder mehrere der Header-Felder X-MMS- 
Content-ID, X-MMS-Content-Size, X-MMS-Content-Type generiert 
oder aktualisiert . 

15 

21. Verfahren nach einem der Anspruche 1 bis 20, 
dadurch gekennzeichnet, 

dafi das oder die Identif izierungssignal (e) jeweils in der Be- 
nachrichtigung an den Empfanger (MMS user agent B) durch das 
20 MMS Relay des Service Providers ttber das Vorhandensein eines 
oder mehrerer neuen Datensatze einer Multimedia message liber- 
tragen wird. 

22. Verfahren nach einem der Anspruche 1 bis 21, 
25 dadurch gekennzeichnet, 

dafi dem Telekommunikationsgerat des Empfangers eine Wahlein- 
richtung zugeordnet ist, mittels der dieser nach zumindest 
teilweiser Kenntnisnahme des oder der Identif ikationssig- 
nal(e) eine Bestatigung der Empf angsbereitschaf t fur den Da- 
30 tensatz geben kann, und die Obertragung zum Empfanger erst 
nach Auslosung der Wahleinrichtung ermoglicht ist. 

23. Verfahren nach Anspruch 22, 
dadurch gekennzeichnet, 

35 daJi sich die Empf angsbereitschaf t nur auf einen Teil der Da- 
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ten bezieht und die Ubertragung nur dieses Teils des Daten- 
satzes f reigeschaltet wird. 

24. Verfahren nach einem der Anspriiche 1 bis 23, 
5 dadurch gekennzeichnet, 

dafi das oder die zusatzlichen Identif izierungssignal (e) der 
Benachrichtigung iiber bereitstehende Daten (M- 
Notification.ind) und der eigentlichen Datensendung (M- 
Retrieve . conf ) zugefiigt werden. 

10 

25. Verfahren nach einem der Anspriiche 1 bis 24, 
dadurch gekennzeichnet, 

daJ5 die Bereitschaft zum zumindest teilweisen Empfang der be- 
reitstehenden Daten der vom Empfanger an den Provider gesand- 
15 ten Nachricht WSP Get.req zugeordnet ist. 

26. Mobiltelekommunikationsgerat (5; 6) zur Durchfuhrung des 
Verfahrens nach einem der Anspriiche 1 bis 25, 
dadurch gekennzeichnet, 

20 daJS dem Mobiltelekommunikationsgerat (5; 6) ein Auswahlschal- 
ter (25) zur volligen oder teilweisen Bestatigung oder Ableh- 
nung der Empf angsbereitschaf t fiir einen oder mehrer.e identi- 
fizierten Datensatz oder Datensatze (7) zugeordnet ist. 



25 27. Mobiltelekommunikationsgerat nach Anspruch 26, 
dadurch gekennzeichnet, 

daJJ dem Mobiltelekommunikationsgerat (5; 6) ein Anzeigemittel 
(24) zur optischen oder akustischen Anzeige des oder der I- 
dentif izierungssignale eines oder mehrerer Datensatze (7) zu- 
30 geordnet ist. 

28. Mobiltelekommunikationsgerat nach einem der Anspriiche 26 
oder 27, 

dadurch gekennzeichnet, 
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dafl der Auswahlschalter (25) sof twareseitig implementiert und 
Uber ein Eingabemittel anwahlbar ist. 

29. Mobiltelekommunikationsgerat (5; 6) , 
5 dadurch gekennzeichnet, 

dali diesem eine Software zur Belegung von Header-Feldern 
(17;18/19;20/21/22;23) von Datensendungen mit zumindest einem 
Identif ikationssignal zugeordnet ist . 

10 30. Computerprogrammerzeugnis, das ein computerlesbares 

Speichermedium umfaiit, auf dem ein Programm gespeichert ist, 
das es einem Computer ermoglicht, nachdem es in den Speicher 
des Computers geladen worden ist, innerhalb von Dateniibertra- 
gung in einem Mobilf unknetz den zu tlbertragenden Daten zumin- 

15 dest ein Identif izierungssignal mit charakterisierenden Anga- 
ben zu einem Datensatz (7) oder mehreren Datensatzen (7) an 
den jeweiligen Empf anger (4) weiterzuleiten . 

31. Computerprogrammerzeugnis nach Anspruch 30, 
20 dadurch gekennzeichnet, 

dafi dieses ein Verfahren nach einem der Anspruche 1 bis 25 
bei Datenversand in einem Mobilf unknetz durchfuhrt. 

32 . Funkkommunikationssystem, bei dem mindestens eine Kompo- 
25 nente nach einem Verfahren der vorhergehenden AnsprUche ar- 

beitet . 
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FIG 2 
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X-Mms-Message-Type 



Siehe Stand der Technik 



Siehe Stand der Technik 



X-Mms-Transaction-ID 
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X-Mms-Delivery-Time 



X-Mms-Priority 



17- 

18- 

19- 
20- 

21- 
22- 

23- 



X-Mms-Content-ID 



Content-IDentifier= 
CI 



Optional: Dieses Feld definiert die 
Lokalisierung des MM-Elements 7 



X-Mms-Content-Type 



Content-type-value = 
CTV 



Optional: Spezifiziert den Inhaltstyp des 
MM-Elements 7 



X-Mms-Content-Size 



Content-size-value= 
CSV 



Optional: GesamtgroBe des MM-Elements 
in Octets 



X-Mms-Content-Name 



Content-name =CNV 



Optional: Name des MM-Elements 7 



X-Mms-Content-Related-URI 



Location-value =LV 



Optional: Definiert die Lokalisierung eines 
anderen MM-Elements, auf das das 
beschriebene MM-Element 7 bezogen ist 



X-Mms-External-Link-Flag 



Extemal-Link-Flag= 
ELF 



Optional: Zeigt an, wenn die MM oder eine seiner 
MM-Elemente einen Link zu einem Element 
auBerhalb der gesamten MM enthalt 



X-Mms-External-Link-Size 



External-Link-Size= 
ELS 



Optional: GesamtgroBe des gelinkten externen 
Elements in Octets 
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FIG 3 

172-^X-Mms-Content-ID (0x80): 

CI = Text-string (Textzeichen) 

1 82 — X-Mms-Content-Type (0x81 ): 

CTV = short-integer (ganze Zahl) 

X-Mms-Content-Size (0x82): 

CSV = short-integer (ganze Zahl) 

202-^X-Mms-Content-Name (0x83): 

CN = Text-string (Textzeichen) 

212--- X-Mms-Content-Related-URI (0x84): 
CRV = Text-string (Textzeichen) 

222--- X-Mms-External-Link-Flag (0x85): 
ELF = Yes | No (Ja/Nein) 
Yes = < Octet 1 28 > 
No = <0ctet129> 

232 X-Mms-External-Link-Size(0x86): 

ELS = short-integer (ganze Zahl) 

X-Mms-Status (0x14): 
Status-Value = Expir ed | Retrieved | 
Rejected | Deferred HPartly-retrieved 



Expired = < Octet 1 28 > 
Retrieved = <Octet129> 
Rejected = < Octet 1 30 > 
Deferred = <0ctet131> 
I Partly-retrieved = <Octetl32> 
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FIG 4 
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FIG 5 
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FIG 6 mrc 
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FIG 7 
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Q M-Send.req (MMS User Agent A -» MMS Relay): 

X-Mms-Message-Type: m-send-req 
X-Mms-Transaction-ID: TRANSACTI0N-ID#1 
X-Mms-Version: 1.0 
Date: Fri, 14 Jul 2000 14:12:19 +0100 
From: markus.traubera@t~online.de 
To: andreas.schmidtOsal.siemens.de 
To: josef.laumen(5)sal.siemens.de 
Subject: Urlaubsgruesse aus Spiekeroog 
X-Mms-Delivery-Report: Yes 

X-Mms-Content-ID: <000714.1412.1markus.trauberg > 
X-Mms-Content-Name: "Urlaubsgruesse.txt" 
X-Mms-External-Link-Flag: Yes 
X-Mms-External-Link-Size: 8245 
X-Mms-Content-ID: <000714.1412.2markus.trauberg > 
X-Mms-Content-Name: "unser Ferienhaus.jpg" 
X-Mms-Content-ID: <000714.1412.3markus.trauberg > 
X-Mms-Content-Name: "Spiekeroog.smi" 
X-Mms-Content-Related-ID: <000714.1412.2markus.trauberg > 
X-Mms-Content-Related-ID: <000714.1412.4markus.trauberg > 
X-Mms-Content-Related-ID: < 00071 4.1 41 2.5markus.trauberg > 
X-Mms-Content-ID: <000714.1412.4markus.trauberg > 
X-Mms-Content-Name: "Meeresrauschen .mp3" 
X-Mms-Content-ID: <000714.1412.5markus.trauberg > 
X-Mms-Content-Name: "Inselbahn .mpg w 
Content-Type: Application/vnd.wap.multipart.related 
Start: <000714.1412.3.markus.trauberg > 
nEntries: 5 
HeadersLen: XX 
DataLen: XX 

Content-Type: text/plain; 

X-Mms-Content-ID: <000714.1412.1markus.trauberg > 
Liebe Kollegen, 

Schone GruBe aus dem Urlaub. Spiekeroog ist mat wieder ganz bezaubernd. 

Falls ihr auf den Geschmack kommt, findet ihr hier mehr Info: http://www.spiekeroog.de 

Viel SpaS noch bei der Arbeit ;-) 

MfG 

Markus 

HeadersLen: XX 
DataLen: 1265 
Content-Type: image/jpeg 

X-Mms-Content-ID: <000714.1412.2markus.trauberg > 

HeadersLen: XX 
DataLen: 588 

Content-Type: presentation jiescription/smil, 
X-Mms-Content-ID: <000714.1412.3markus.trauberg > 

HeadersLen: XX 
DataLen: 82345 
Content-Type: audio/mp3, 

X-Mms-Content-ID: <000714.1412.4markus.trauberg > 

HeadersLen: XX 
DataLen: 632564 
Content-Type: video/mpeg4 

X-Mms-Content-ID: <000714.1412.5markus.trauberg > 
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FIG 10 

M-Send.conf (MMS Relay -> MMS User Agent A ) : 

X-Mms-Message-Type: m-send-conf 
X-Mms-Transaction-ID: TRANSACTI0N-ID#1 
X-Mms-Version: 1 .0 
X-Mms-Message-ID: MESSAGE-ID#1 
X-Mms-Response-Status: ok 
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FIG 11 

M-Notification.ind an einen "To-Empfanaer": 

X-Mms-Message-Type: m-notification-ind 
X-Mms-Transaction-ID: TRANSACTI0N-ID#2 
X-Mms-Version: 1 .0 
From: markus.traubera(5)t-online.de 
X-Mms-Message-Class: Personal 
X-Mms-Message-Size: XXX (Attachments + Header) 
X-Mms-Expiry: 3600 

X-Mms-Content-Location: www.sal.siemens.de/mms-inbox/ABCD.1234 

Subject: Urlaubsgruesse aus Spiekeroog 

X-Mms-Content-ID: <000714.1412.1markus.trauberg > 

Content-Type: text/plain 

X-Mms-Content-Name: "Urlaubsgruesse.txt" 

X-Mms-Content-Size: 212 

X-Mms-External-Link-Flag: Yes 

X-Mms-External-Link-Size: 8245 

X-Mms-Content-ID: <000714.1412.2markus.trauberg > 

Content-Type: image/jpeg 

X-Mms-Content-Name: "unser Ferienhaus.jpg" 

X-Mms-Content-Size:1265 

X-Mms-Content-ID: <000714.1412.3markus.trauberg > 
Content-Type: presentation_description/smil 
X-Mms-Content-Name: "Spiekeroog.smi" 
X-Mms-Content-Size: 588 

X-Mms-Content-Related-ID: < 00071 4.1 41 2.2markus.trauberg > 
X-Mms-Content-Related-ID: <000714.1412.4markus.trauberg > 
X-Mms-Content-Related-ID: <000714.1412.5markus.trauberg > 
X-Mms-Content-ID: <000714.1412.4markus.trauberg > 
Content-Type: audio/mp3 
X-Mms-Content-Name: "Meeresrauschen .mp3" 
X-Mms-Content-Size: 82345 
X-Mms-Content-ID: <000714.1412.5markus.trauberg > 
Content-Type: video/mpeg4 
X-Mms-Content-Name: "Inselbahn .mpg" 
X-Mms-Content-Size; 632564 
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FIG 12 

M-Retrieve.conf (MMS Relay -> MMS User Aaent BV 

X-Mms-Message-Type: m-retrieve-conf 

X-Mms-Transaction-ID:TRANSACTION-ID#3 

X-Mms-Version: 1.0 

Date: Fri, 14 Jul 2000 14:12:19 +0100 

From: markus.traubemOt-online.de 

To: andreas.schmidt(5)sal .siemens.de 

To: iosef.laumen(5>sal .siemens.de 

X-Mms-Message-ID: MESSAGE-ID#1 

X-Mms-Delivery-Report: Yes 

Subject: Urlaubsgruesse aus Spiekeroog 

Content-Type: Application/vnd.wap.mulitpart.related 

Start: <000714.1412.3markus.trauberg > 

nEntries: 5 

HeadersLen: XX 

DataLen: XX 

Content-Type: text/plain; 

X-Mms-Content-ID: <000714.1412.1markus.trauberg > 
X-Mms-Content-Name: "Urlaubsgruesse.txt" 
Liebe Kollegen, 

Schone GruBe aus dem Urlaub. Spiekeroog ist mal wieder ganz bezaubernd. 

Falls ihr auf den Geschmack kommt, findet ihr hier mehr Info: 
http://www.SDiekerooa.de 

Viel SpaB noch bei der Arbeit ;-) 

MfG 

Markus 

HeadersLen: XX 
DataLen: 1265 
Content-Type: image/jpeg 
X-Mms-Content-Name: "unser Ferienhaus.jpg" 
X-Mms-Content-ID: <000714.1412.2markus.trauberg > 

HeadersLen: XX 
DataLen: 588 

Content-Type: presentation description/smil, 
X-Mms-Content-Name: "Spiekeroog.smi" 
X-Mms-Content-ID: < 00071 4.1 41 2.3markus.trauberg > 

HeadersLen: XX 
DataLen: 82345 
Content-Type: audio/mp3, 
X-Mms-Content-Name: "Meeresrauschen .mp3" 
X-Mms-Content-ID: <000714.1412.4markus.trauberg > 

HeadersLen: XX 
DataLen: 632564 
Content-Type: video/mpeg4 
X-Mms-Content-Name: "Inselbahn .mpg" 
X-Mms-Content-ID: < 00071 4.1 41 2.5markus.trauberg > 



WO 02/058359 



12/21 



PCT/EPO 1/14617 



FIG 13 

M-Acknowledae.ind (MMS User Agent B -> MMS Relay) : 

X-Mms-Message-Type: m-acknowledge-ind 
X-Mms-Transaction-ID: TRANSACTI0N-ID#3 
X-Mms-Version: 1 .0 
X-Mms-Report-AI lowed: Yes 



FIG 14 

M-Deliverv.ind (MMS Relay -> MMS User Agent A) : 

X-Mms-Message-Type: m-delivery-ind 
X-Mms-Transactlon-ID: MESSAGE-ID#1 
X-Mms-Version: 1 .0 
To: andreas.schmidt(5)sal.siemens.de 
Date: Fri, 14 Jul 2000 16:45:00 +0100 
X-Mms-Status: Retrieved 
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FIG 15 

M-Retrieve.conf (MMS Relay -> MMS User Agent B): 

X-Mms-Message-Type: m-retrieve-conf 

X-Mms-Transaction-ID: TRANSACTI0N-ID#4 

X-Mms-Version: 1 .0 

Date: Fri, 14 Jul 2000 14:12:19 +0100 

From: markus.trauberQ(a>t-online.de 

To: andreas.schmidt(5>sal .siemens.de 

To: )osef.laumen(5)sal.siemens.de 

X-Mms-Message-ID: MESSAGE-ID#1 

X-Mms-Delivery-Report: Yes 

Subject: Urlaubsgruesse aus Spiekeroog 

Content-Type: Application/vnd.wap.mulitpart.related 

Start: <000714.1412.3markus.trauberg > 

nEntries: 1 

HeadersLen: XX 

DataLen: XX 

Content-Type: text/plain; 

X-Mms-Content-ID: <000714.1412.1markus.trauberg > 
X-Mms-Content-Name: "Urlaubsgruesse.txt" 
Liebe Kollegen, 

Schone GruBe aus dem Urlaub. Spiekeroog ist mal wieder ganz 
bezaubernd. 

Falls ihr auf den Geschmack kommt, findet ihr hier mehr Info: 
httD.7/www.spiekerooa.de 

Viel SpaB noch bei der Arbeit ;-) 

MfG 

Markus 
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FIG 16 

M-Acknowledae.ind (MMS User Agent B — > MMS Relay) : 

X-Mms-Message-Type: m-acknowledge-ind 
X-Mms-Transaction-ID: TRANSACTI0N-ID#4 
X-Mms-Version: 1 .0 
X-Mms-Report-AI lowed: Yes 



FIG 17 

M-Deliverv.ind (MMS Relay -> MMS User Agent A) : 

X-Mms-Message-Type: m-delivery-ind 

X-Mms-Transaction-ID: TRANSACTI0N-ID#1 

X-Mms-Version: 1 .0 

To: iosef.laumen(5)sal. siemens.de 

Date: Fri, 14 Jul 2000 '15:57:13 +0100 

X-Mms-Status: Partly-retrieved 
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FIG 18 

X-Mms-Content-ID (0x19) 

X-Mms-Content-ID-value = Text-string | X-Mms-Content-general-form 

X-Mms-Content-general-form = Value-length Text-string 

* (Parameter) 
(Codierungstypen gemaG [2] und [3]) 



i 



FIG 19 
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FIG 20 
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FIG 21 A 
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FIG 21 B 
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FIG 23 

M-SraqfM-UAA-> M-SR) : 

X-Mms-Message-Type: m-send-req 

X-Mms-Transaction-ID: TRANSACTI0N-ID#1 

X-Mms-Version: 1.0 

Date: Fri, 14 Jul 2000 14:12:19 +0100 

From: markus.traubera@t-online.de 

To: andreas.schmidt@sal.siemens.de 

Subject: Urlaubsgruesse aus Spiekeroog 

X-Mms-Delivery-Report: Yes 

X-Mms-Content-ID: <0Q0714.1412.1markus.trauberg >; Name = 

"Urlaubsgruesse.txt"; External-Link-Flag = Yes; 

External-Link-Size = 8245 
X-Mms-Content-ID: <000714.1412.2markus.trauberg >; Name = "unser Ferienhaus.jpg u 
X-Mms-Content-ID: <000714.1412.3markus.trauberg >; Name = Spiekeroog.smi"; Related-ID = 

<000714.1412.2markus.trauberg >; Related-ID = 

<000714.1412.4markus.trauberg >; Related-ID = 

<000714.1412.5markus.trauberg > 
X-Mms-Content-ID: < 00071 4.1 41 2.4markus.trauberg >; Name = "Meeresrauschen .mp3" 
X-Mms-Content-ID : <Q00714.1412.5markus,trauberg >; Name == "Inselbahn .mpg" 

Content-Type: Application/vnd.wap.multipart.related: Start = < 00071 4.1 41 2.3markus.trauberg > 
nEntries: 5 
HeadersLen: XX 
DataLen: XX 

Content-Type: text/plain; 

fx^Mms-Content-ID: <000714.1412.1markus.trauberg > | 
Liebe Kollegen, ~" _— 

Schone GruBe aus dem Urlaub. Spiekeroog ist mal wieder ganz bezaubernd. 
Falls ihr auf den Geschmack kommt, findet ihr hier mehr Info: httD://www.SDiekerooo.de 
Viel SpaB noch bei der Arbeit ;-) 
MfG 
Markus 

HeadersLen: XX 
DataLen: 1265 

Content-Type: image/jpeg 

X-Mms-Content-ID: <000714.1412.2markus.trauberg > | 

HeadersLen: XX 
DataLen: 588 

Content-Type: application/smil, 

X-Mms-Content-ID: < 00071 4.1 41 2.3markus.trauberg > 

HeadersLen: XX 
DataLen: 82345 

Content-Type: audio/mp3 t 

X-Mms-Content-ID: <000714.1412.4markus.trauberg > [ 

HeadersLen: XX 
DataLen: 632564 

Content-Type: video/mpeg4 

X-Mms-Content-ID: <000714.1412.5markus.trauberg > ' I 
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FIG 24 

M-Nind an einen "To-Empfanaer": 

X-Mms-Message-Type: m-notification-ind 
X-Mms-Transaction-ID: TRANSACTI0N-ID#2 
X-Mms-Version: 1 .0 
From: markus.traubera(g>t-online.de 
X-Mms-Message-Class: Personal 
X-Mms-Message-Size: XXX (Attachments + Header) 
X-Mms-Expiry: 3600 

X-Mms-Content-Location: www.sal.siemens.de/mns-inbox/ABCD.1234 
Subject: Urlaubsgruesse aus Spiekeroog 

X-Mms-Content-ID:<000714.1412.1markus.trauberg >;Type = 
text/plain; Name = "Urlaubsgruesse.txt"; Size = 212; 
External-Link: Yes; External-Link-Size = 8245 

X-Mms-Content-ID:< 00071 4.1 41 2.2markus.trauberg >;Type = 

image/bmp; Name = "unser Ferienhaus.bmp"; Size = 
5863; Original-Type = image/jpeg; Original-Size = 1265 

X-Mms-Content-ID:<000714.1412.3markus.trauberg >;Type = 
application/smil; Name = Spiekeroog.smi"; 
Content-Size = 588; Related-ID = 
<000714.1412.2markus.trauberg >; Related-ID = 
< 00071 4.1 41 2.4markus.trauberg >; Related-ID = 
<000714.1412.5markus.trauberg > 

X-Mms-Content-ID:< 00071 4.1 41 2.4markus.trauberg >;Type = 
audio/mp3 ; Name = "Meeresrauschen .mp3"; 
Size = 82345 

X-Mms-Content-ID :< 00071 4.1 41 2.5markus.trauberg >; Type = 

video/mpeg4; Name = "Inselbahn .mpg" ; Size = 632564 
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FIG 25 

M-Rconf (M-SR-» M-UAB): 

X-Mms-Message-Type: m-retrieve-conf 
X-Mms-Transaction-ID:TRANSACTION-ID#3 
X-Mms-Version: 1 .0 
Date: Fri, 14 Jul 2000 14:12:19 +0100 
From: markus.trauberoOt-onl ine.de 
To: andreas.schmidt@sal.siemens.de 
X-Mms-Message-ID: MESSAGE-ID#1 
Subject: Urlaubsgmesse aus Spiekeroog 
X-Mms-Delivery-Report: Yes 

Content-Type: Appl i cation/vnd. wap . mu Itipart. related ; Start = < 00071 4.1 41 2.3.markus.trauberg > 
nEntries: 5 
HeadersLen: XX 
DataLen: XX 

Content-Type: text/plain; 
| X-Mms-Content-ID: <000714.1412.1markus.trauberg >; Name = "Urlaubsgruesse.txt" | 
Liebe Kollegen, 

Schone GruBe aus dem Urlaub. Spiekeroog ist mal wieder ganz bezaubernd. 

Falls ihr aut den Geschmack kommt, findet ihr hier mehr Info: httD://www.spiekerooo.de 

Viel SpaB noch bei der Arbeit ;-) 

MfG 

Markus 

HeadersLen: XX 
DataLen: 5863 

Content-Type: image/bmp 



X-Mms-Content-ID: < 00071 4.1 41 2.2markus.trauberg >; Name = 




"unser Ferienhaus.bmp"; Original-Type = image/jpeg; 


Original-Size = 1265 




HeadersLen: XX 




DataLen: 588 




Content-Type: application/smil, 




X-Mms-Content-ID: < 00071 4.1 41 2.3markus.trauberg >; Name = 


Spiekeroog.smi" 


HeadersLen: XX 




DataLen: 82345 




Content-Type: audio/mp3, 




X-Mms-Content-ID: < 0007 14.1 41 2.4markus.trauberg >; Name = 


"Meeresrauschen .mp3"j 


HeadersLen: XX 




DataLen: 632564 




Content-Type: video/mpeg4, 




| X-Mms-Content-ID: < 00071 4.1 41 2.5markus.trauberg >; Name = 


"Inselbahn .mpg" | 
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